I believe if proper handling for KeyError would be implemented here:
https://github.com/cloudfoundry-community/cf-python-client/blob/49089eef965ceb95babe1053cdf5b503a0c5f656/cloudfoundry_client/v3/entities.py#L218C1-L219C37
We could fallback and re-initiate accessed object if attribute accessed is missing in object crafted from includes returned by fields. So as long as you are looking for guid and name from fields, it wouldn't trigger extra calls. I believe you would know better how to handle it here. Somehow I am yet lost in this project implementation 😄

@krismarc I am ok to offer the possibility to declare ask the backend to return only necessary fields; however, when it comes to KeyError, I would prefer not implement a fallback which could turn in a great complexity on code side.... And maybe in a endless loop if the accesssed key would not exist. If the caller asks for specific fields and tries to access some others... well... That's his/her problem.

I would like some unit tests just to garantee there is no issue..now and in the future.

After re-reading the code I see thats navigation and links already has fallback on empty object so I don't think it will break on missing fields

@antechrestos, sorry, I've missed your response. By any chance, are you able to generate test payloads? If not, I will handle somehow. Does it also mean, that you agree with the way how to declare that ask to the backend?
eg.
fields = {"space.organization": ["guid", "name"], "space": ["guid,name,relationships.organization"] }
service_instances = client.v3.service_instances.list(fields=fields)

Regarding that fallback, this was also my impression and why I suggested that you know the code better than anyone else 😄

btw, I've also raised a question with controller maintainers why there are no includes for service instances -> cloudfoundry/cloud_controller_ng#4450, I'd love this one in combination with this project. As I've mentioned here. In combination with includes, reading CF would be really fast.

damn.. while writing test, I've realized, that GET on a single object doesn't populate relationship with org. you simply have to trust that org returned in "includes" is the actual org of given space. So depending on the endpoint type you would have to handle differently.

That differs to actual real includes which always have relationship present.

This API is too much overthought😅

To support this, we would have to blindly trust and create additional objects out of includes (if GET, not a LIST operation)
or append payload dynamically so this client knows how to handle it. Both options sound to me like repairing some inconsistency.

Alternative approach would be to not care about this and user needs to be aware that child objects are populated only if relationship was intentionally requested and returned by the api.

@antechrestos I've added a note within readme and tests for service instances. Would that be sufficient?

@krismarc everything seems well despite the fact thtwe use lint. You can check linting by running

poetry run flake8 --show-source --statistics

@krismarc everything seems well despite the fact thtwe use lint. You can check linting by running

poetry run flake8 --show-source --statistics

done

@krismarc thank you for your contribution.
I will make a fresh release by the next days.
Cheers 🍻

@krismarc 1.39.0 released